Internet Engineering Task Force (IETF) A. Melnikov 


Request for Comments: 5788 D. Cridland 
Category: Standards Track Isode Limited 
ISSN: 2070-1721 March 2010 


IMAP4 Keyword Registry 
Abstract 
The aim of this document is to establish a new IANA registry for IMAP 
keywords and to define a procedure for keyword registration, in order 
to improve interoperability between different IMAP clients. 
Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5788. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


IMAP keywords [RFC3501] are boolean named flags that can be used by 
clients to annotate messages in an IMAP mailbox. Although IMAP 
keywords are an optional feature of IMAP, the majority of IMAP 
servers can store arbitrary keywords. Many mainstream IMAP clients 
use a limited set of specific keywords, and some can manage (create, 
edit, display) arbitrary IMAP keywords. 


Over the years, some IMAP keywords have become de-facto standards, 
with some specific semantics associated with them. In some cases, 
different client implementors decided to define and use keywords with 
different names, but the same semantics. Some server implementors 
decided to map such keywords automatically in order to improve cross- 
client interoperability. 


In other cases, the same keywords have been used with different 
semantics, thus causing interoperability problems. 


This document attempts to prevent further incompatible uses of IMAP 
keywords by establishing an "IMAP Keywords" registry and allocating a 
special prefix for standardized keywords. 

2. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [Kwds]. 
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3; 


IANA Considerations 

IANA has established a new registry for IMAP keywords. 

Registration of an IMAP keyword is requested by filling in the 

following template and following the instructions on the IANA pages 

for the registry to submit it to IANA: 

Subject: Registration of IMAP keyword X 

IMAP keyword name: 

Purpose (description): 

Private or Shared on a server: (One of PRIVATE, SHARED, or BOTH. 
PRIVATE means that each different 
user has a distinct copy of the 
keyword. SHARED means that all 
different users see the same value of 
the keyword. BOTH means that an IMAP 
server can have the keyword as either 
private or shared.) 

Is it an advisory keyword or may it cause an automatic action: 


When/by whom the keyword is set/cleared: 


Related keywords: (for example, "mutually exclusive with keywords Y 
and Z") 


Related IMAP capabilities: 

Security considerations: 

Published specification (recommended) : 

Person & email address to contact for further information: 


Intended usage: (One of COMMON, LIMITED USE, or DEPRECATED (i.e., 
not recommended for use) ) 


Owner/Change controller: (MUST be "IESG" for any "common use" 
keyword registration specified in an IETF 
Review document. See definition of "common 


use" below in this section. When the 
Owner/Change controller is not a 
Standardization Organization, the 
registration request MUST make it clear if 
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the registration is controlled by a 
company, or the individual performing the 
registration.) 


Note: (Any other information that the author deems interesting 
may be added here, for example, if the keyword(s) is 
supported by existing clients.) 


Registration of an IMAP keyword requires Expert Review [RFC5226]. 
Registration of any IMAP keyword is initiated by posting a 
registration request to the Message Organization WG mailing list 
<morg@ietf.org> (or its replacement as chosen by the responsible 
Application Area Director) and CCing IANA (<iana@iana.org>). After 
allowing for at least two weeks for community input on the designated 
mailing list, the expert will determine the appropriateness of the 
registration request and either approve or disapprove the request 
with notice to the requestor, the mailing list, and IANA. Any 
refusal must come with a clear explanation. 


The IESG appoints one or more Expert Reviewers for the IMAP keyword 
registry established by this document. 


The Expert Reviewer should strive for timely reviews. The Expert 
Reviewer should take no longer than six weeks to make and announce 
the decision, or notify the mailing list that more time is required. 


Decisions (or lack of) made by an Expert Reviewer can be first 
appealed to Application Area Directors and, if the appellant is not 
satisfied with the response, to the full IESG. 


There are two types of IMAP keywords in the "IMAP Keywords" registry: 
intended for "common use" and vendor-/organization-specific use (also 
known as "limited use"). An IMAP keyword is said to be for "common 
use" if it is reasonably expected to be implemented in at least two 
independent client implementations. The two types of IMAP keywords 
have different levels of requirements for registration (see below). 


3.1. Review Guidelines for the Designated Expert Reviewer 
Expert Reviewers should focus on the following requirements. 
Registration of a vendor-/organization-specific ("limited use") IMAP 
keyword is easier. The Expert Reviewer only needs to check that the 
requested name doesn’t conflict with an already registered name, and 


that the name is not too generic, misleading, etc. The Expert 
Reviewer MAY request the IMAP keyword name change before approving 
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the registration. The Expert Reviewer SHOULD refuse a registration 
if there is an already registered IMAP keyword that serves the same 
purpose, but has a different name. 


When registering an IMAP keyword for "common use", the Expert 
Reviewer performs the checks described for vendor-/ 
organization-specific IMAP keywords, plus additional checks as 
detailed below. 


Keywords intended for "common use" SHOULD start with the "$" prefix. 
(Note that this is a SHOULD because some of the commonly used IMAP 
keywords in widespread use don’t follow this convention.) 


IMAP keywords intended for "common use" SHOULD be standardized in 
IETF Review [RFC5226] documents. (Note that IETF Review documents 
still require Expert Review.) 


Values in the "IMAP Keywords" IANA registry intended for "common use" 
must be clearly documented and likely to ensure interoperability. 
They must be useful, not harmful to the Internet. In cases when an 
IMAP keyword being registered is already deployed, Expert Reviewers 
should favor registering it over requiring perfect documentation 
and/or requesting a change to the name of the IMAP keyword. 


The Expert Reviewer MAY automatically "upgrade" registration requests 
for a "limited use" IMAP keyword to "common use" level. The Expert 
Reviewer MAY also request that a registration targeted for "common 
use" be registered as "limited use" instead. 


3.2. Comments on IMAP Keywords’ Registrations 


Comments on registered IMAP keywords should be sent to both the 
"owner" of the mechanism and to the mailing list designated to IMAP 
keyword review (see Section 3). This improves the chances of getting 
a timely response. 


Submitters of comments may, after a reasonable attempt to contact the 
owner and after soliciting comments on the IMAP mailing list, request 
the designated Expert Reviewer to attach their comment to the IMAP 
keyword registration itself. The procedure is similar to requesting 
an Expert Review for the affected keyword. 


3.3. Change Control 


Once an IMAP keyword registration has been published by IANA, the 
owner may request a change to its definition. The change request 
(including a change to the "intended usage" field) follows the same 
procedure as the initial registration request, with the exception of 
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changes to the "Person & email address to contact for further 
information" and "Owner/Change controller" fields. The latter can be 
changed by the owner by informing IANA; this can be done without 
discussion or review. 


The IESG may reassign responsibility for an IMAP keyword. The most 
common case of this will be to enable clarifications to be made to 
keywords where the owner of the registration has died, moved out of 
contact, or is otherwise unable to make changes that are important to 
the community. 


IMAP keyword registrations MUST NOT be deleted; keywords that are no 
longer believed appropriate for use can be declared DEPRECATED by a 
change to their "intended usage" field. 


The IESG is considered the owner of all "common use" IMAP keywords 
that are published in an IETF Review document. 


3.4. Initial Registrations 


IANA has registered the IMAP keywords specified in following 
subsections in the registry established by this document. 


3.4.1. SMDNSent IMAP Keyword Registration 


Subject: Registration of IMAP keyword SMDNSent 


IMAP keyword name: $MDNSent 


Purpose (description): Specifies that a Message Disposition 
Notification (MDN) must not be sent for any 
message annotated with the SMDNSent IMAP 
keyword. 


Private or Shared on a server: SHARED 


Is it an advisory keyword or may it cause an automatic action: 
This keyword can cause automatic action by 
the client. See [RFC3503] for more details. 


When/by whom the keyword is set/cleared: 
This keyword is set by an IMAP client when it 
decides to act on an MDN request, or when 
uploading a sent or draft message. It can 
also be set by a delivery agent. Once set, 
the flag SHOULD NOT be cleared. 
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Related keywords: None 

Related IMAP capabilities: None 

Security considerations: See Section 6 of [RFC3503] 
Published specification (recommended): [RFC3503] 


Person & email address to contact for further information: 
Alexey Melnikov <alexey.melnikov@isode.com> 


Intended usage: COMMON 
Owner/Change controller: IESG 
Note: 
3.4.2. S$Forwarded IMAP Keyword Registration 
Subject: Registration of the IMAP keyword SForwarded 
IMAP keyword name: $Forwarded 


Purpose (description): $Forwarded is used by several IMAP clients to 
specify that the message was resent to 
another email address, embedded within or 
attached to a new message. This keyword is 
set by the mail client when it successfully 
forwards the message to another email 
address. Typical usage of this keyword is to 
show a different (or additional) icon for a 
message that has been forwarded. 


Private or Shared on a server: BOTH 


Is it an advisory keyword or may it cause an automatic action: 
advisory 


When/by whom the keyword is set/cleared: 
This keyword can be set by either a delivery 
agent or a mail client. Once set, the flag 
SHOULD NOT be cleared. Notes: There is no 
way to tell if a message with $Forwarded 
keyword set was forwarded more than once. 


Related keywords: None 


Related IMAP capabilities: None 
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Security considerations: A server implementing this keyword as a 
shared keyword may disclose that a 
confidential message was forwarded. 


Published specification (recommended): [RFC5550] 


Person & email address to contact for further information: 
Alexey Melnikov <alexey.melnikov@isode.com> 


Intended usage: COMMON 

Owner/Change controller: IESG 

Note: 

3.4.3. SSubmitPending IMAP Keyword Registration 

Subject: Registration of IMAP keyword $SubmitPending 

IMAP keyword name: $SubmitPending 

Purpose (description): The SSubmitPending IMAP keyword designates 
the message as awaiting to be submitted. 
This keyword allows storing messages waiting 
to be submitted in the same mailbox where 
messages that were already submitted and/or 
are being edited are stored. 
A message that has both S$Submitted and 
SSubmitPending IMAP keywords set is a message 
being actively submitted. 

Private or Shared on a server: SHARED 

Is it an advisory keyword or may it cause an automatic action: 

This keyword can cause automatic action by 
the client. See Section 5.10 of [RFC5550] 
for more details. 

When/by whom the keyword is set/cleared: 
This keyword is set by a mail client when it 
decides that the message needs to be sent 
out. 


Related keywords: S$Submitted 


Related IMAP capabilities: None 
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Security considerations: A server implementing this keyword as a 
shared keyword may disclose that a 
confidential message is scheduled to be 
sent out or is being actively sent out. 

Published specification (recommended): [RFC5550] 


Person & email address to contact for further information: 
Alexey Melnikov <alexey.melnikov@isode.com> 


Intended usage: COMMON 
Owner/Change controller: IESG 
Note: 
3.4.4. S$Submitted IMAP Keyword Registration 
Subject: Registration of IMAP keyword SSubmitted 
IMAP keyword name: S$Submitted 


Purpose (description): The $Submitted IMAP keyword designates the 
message as being sent out. 


A message that has both S$Submitted and 
SSubmitPending IMAP keywords set is a message 
being actively submitted. 


Private or Shared on a server: SHARED 


Is it an advisory keyword or may it cause an automatic action: 
This keyword can cause automatic action by 
the client. See Section 5.10 of [RFC5550] 
for more details. 


When/by whom the keyword is set/cleared: 
This keyword is set by a mail client when it 
decides to start sending it. 
Related keywords: $SubmitPending 
Related IMAP capabilities: None 
Security considerations: A server implementing this keyword as a 
shared keyword may disclose that a 


confidential message was sent or is being 
actively sent out. 
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6. 


6. 


Published specification (recommended): [RFC5550] 


Person & email address to contact for further information: 
Alexey Melnikov <alexey.melnikov@isode.com> 


Intended usage: COMMON 
Owner/Change controller: IESG 
Note: 
Security Considerations 
IMAP keywords are one of the base IMAP features [RFC3501]. This 
document doesn’t change their behavior, so it does not add new 
security issues. 
A particular IMAP keyword might have specific security 
considerations, which are documented in the IMAP keyword 
registration template standardized by this document. 
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